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ABSTRACT 



The Director of Naval Reserve and Commander, Naval Reserve 
Force (CNRF) are totally dependent on the Commanding Officer, 
Naval Reserve Personnel Center (NRPC) and the Inactive 
Manpower and Personnel Information System (IMAPMIS) automated 
information system for the control of all functions of 
Selected Reserve (SELRES) mobilization billet information, 
personnel billet assignments, personnel pay and tracking 
individual mexaber retirement credit. Although recently 
converted from a flat file system to a relational database, 
IMAPMIS does not meet functional requirements for timely 
update and correction of critical data. IMAPMIS's poor 
responsiveness and lack of ad hoc query capadsility make it 
obsolete and virtually unusable for SELRES data. The purpose 
of this thesis is to examine the present functions of IMAPMIS 
and identify its shortfalls. This is followed by a 
recommended alternative to establish a separate SELRES 
database, administered by CNRF, that will internally process 
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I. INTRODnCTION 


Since the beginning of automated data recording, Com- 
memder. Naval Military Personnel Command (NMPC) has been 
responsible for overall control of records, file systems, and 
databases that pertain to the personnel associated with the 
United States Navy. For active duty personnel, these files 
are maintained in Washington, DC by NMPC. For Naval Reserves, 
files are maintained under the jurisdiction of the Naval 
Reserve Personnel Center (NRPC) in New Orleans, LA. Thus, 
NRPC is responsible for: 

1. maintaining up-to-date mobilization billets and 
individual member training assignments 

2. overall data collection, record maintenance and 
updates for inactive naval reserve personnel 

3. provide accurate participation/retirement point credit 
for inactive naval reserve personnel, and retirement 
point capture process 

4. supply accurate drill euid ACDUTRA participation and 
retirement data to the Naval Finance Center in 
Cleveland for Reserve pay matters, and 
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5. ensuring accurate, timely data is available for 
external sources and formal reports to the Congress, 
the Department of Defense as reguested 

The automated system that accounts for the maintenance, 
update and control of these records is the Inactive Reserve 
Manpower and Personnel Management Information System 
(IMAPMIS). IMAPMIS is the official source of all Inactive 
Reserve Personnel Information and is central to all Naval 
Reserve components and applications. 

Director cf Naval Reserve (OP~095) and Commander, Naval 
Reserve Force (CNRF) are responsible for the training, 
preparedness and actual mobilization of the Selected Reserve. 
They are dependent on NRPC for accurate data input, 
corrections, timely updates and information flows that affect 
all aspects of Reserve personnel assets. Until recently, this 
reliance has been a memdated necessity since neither OP-OSS 
nor CNRF has had the personnel or capability to maintain their 
own data. However, once a reservist's record has been 
established within IMAPMIS at NRPC, CNRF has historically 
assumed responsibility for collecting data for Selected 
Reserves. In August 1989, CNRF implemented a new automated 
dateJsase system that enables all 417 Naval Reserve activities 
to upload dally data transactions from their Individual 
databases to a mainframe at CNRF in New Orleans, LA via 
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nightly telecommunication transmissions. With this new in- 
house mainframe data processing capability at CNRF and direct 
link to all field activities, it is now possible for CNRF to 
collect, automate and process data internally. Using standard 
built-in edit functions for format, range and acceptable 
parameters, data is verified immediately (Schwartz, 1989,pp.49- 
50). Additionally, all data uploaded nightly to CNRF is 
processed on a daily basis and errors resulting from database 
inconsistencies are transmitted to the field for corrections 
the next working day. By affording the capability to collect 
^md input data at its source, this provides a significant 
improvement in the timeliness and accuracy of data. Within 
IMAPMIS, errors that could take as much as sixty days to 
identify and resolve can now theoretically be corrected in one 
to two days. 

In view of this recent capability at CNRF, the goal of 
this thesis is to address problems with IMAPMIS and examine 
issues concerning the feasibility of establishing a separate 
corporate database for the Selected Reserve, independent of, 
yet supportive to IMAPMIS. Chapter I presents the background 
and history of the current system and introduces some of the 
idiosyncrasies within the Naval Reserve. The second chapter 
provides a description of problems and shortfalls of existing 
data flow architectures, extensive data passing among systems, 
and how these factors impact on the Naval Reserve Force. 
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Chapter III describes policy issues and additional 
considerations that must be addressed before additional time 
and effort are expended for the improvement of IMAPMIS and 
chapter IV suggests an improved data flow architecture to 
support a separate Naval Reserve database independent of the 
present NRPC/NHPC database. Chapter V will provide 
conclusions and recommendations to further enhance the 
usefulness and quality of this independent database. 

A. BACKGROUND 

A first consideration to examining the scope and ramifi¬ 
cations of this Initiative requires a basic understanding of 
the organizational structure of the Selected Reserve. The 
Naval Reserve is comprised of personnel assets available to 
the Navy in the event of total or partial mobilization. 
Inactive Naval Reserve Personnel are functionally divided into 
two broad segments. The first segment consists of 
approximately 131,000 men and women who participate in monthly 
training at one of the 417 drill sites and participate in 
annual two-week Active Duty for Training (ACDUTRA). This pool 
of personnel is managed by the Commander, Naval Reserve Force. 
The second group, managed by Commander, Naval Reserve 
Personnel Center, is comprised of personnel who have completed 
all of their individual reserve commitments and do not 
participate as drill deck assets. Collectively, there are 
actually six categories of these personnel, and each is 
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briefly described below. Figure 1 shows the categories, 
management responsibilities and approximate numbers of 
members. 

1. Ready Reserves 

Ready Reseirves, more commonly known as Selected 
Reserves (SELRES) or drilling Reserves. These Reservists 
normally drill one weekend per month and participate in Active 
Duty for Training (ACDUTRA) for two weeks each year. Their 
participation is recorded and accumulated in a point system 
on an annual year basis. These points are used to determine 
whether an Individual SELRES has attained a satisfactory 
points total for a "good year" of Reserve participation. As 
with active duty, a Reservist must accrue 20 years of 
satisfactory service to be eligible for retirement. 

2. Individual Ready Reserves 

Individual Ready Reserves (IRR) may fill individual 
military manpower requirements due to their special training, 
skills or professional qualifications (e.g., surgeons). They 
may accrue credit for Reserve participation without actually 
attending drills. They receive pay for their service, and 
are eligible for, but not required to participate in ACDUTRA. 

3. Standby Reserves 

Standby Reserves are classified into two subgroups, 
the Active Standby Reserves (SI status) and the Inactive 
Standby Reserves (S2 Status). 
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RESERVE PERSONNEL CATEGORIES 


Category Managed By 


SELRES —I 

Ready Reserves_| CNRF 


Number 

131,000 


IRR 

Individual 
Ready Reserves 

Standby 
Reserves 
SI and S2 


Fleet 

Reserves 

Retirees 

New 

Accessions 


NRPC 


619,000 


Total 


760,000 


Figure 1. Reserve Personnel Categories 








Active Standby Reserves (SI status) are personnel who 
are eligible for promotion and may drill in a non-pay status. 
They may also complete Navy Training Courses for participation 
euid retirement point credit. However, they are not eligible 
for ACDUTRA. 

Inactive Standby Reserves (S2 status) are not eligible 
to participate in drills, are not eligible for promotion and 
may not accrue retirement point credit. They may, however 
move back to SI Status by signing a Ready Reserve Service 
Agreement. 

4. Fleet Reserves 

Rather than being retired, enlisted members who have 
completed a minimum of 20 years service either on active duty 
or in the Reserves are transferred to the Fleet Reserves for 
a period of up to ten years or 30 years total service. They 
may voluntarily participate, but may not accrue additional 
retirement point credit. They are eligible for recall. 

5. Retirees 

Retirees, both USN and USNR are considered in an 
Inactive status. They may voluntarily participate in a non¬ 
pay status, but ceuinot receive additional retirement point 
credit. They are eligible for recall during mobilization. 
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6. New Accessions 


New accessions from Volunteer and Selective Service 
Draft Categories may be pretrained or untrained assets 
mobilized from the civilian sector. 

In total, the Inactive Naval Reserve Component consists 
of more than 750,000 personnel and their associated service 
and medical records. Maintaining these records requires a 
tremendous 2 unount of data that must be updated and verified 
to ensure that adr^uate personnel resources are ready to 
support and defend the United States. In the event of 
mobilization. Reserve assets will be matched against 
predetermined mobilization billet requirements of active duty 
commands. The billets 2 md mobilization requirements 
themselves are compiled by the Chief of Naval Operations 
(OPNAV) using the classified Naval Manpower Data Accounting 
System (NMDAS). Unclassified reserve billet information is 
subsequently passed through the IMAPMIS system where reports 
are produced for CNRF on the Reserve Unit Manpower 
Authorization System (RUNAS). These reports are used for 
memual structuring Reserve Units. Once structured, the data 
is returned to NRPC for input into IMAPMIS. 

This thesis, in exeunining the establishment of a separate 
SELRES dated>ase, will concentrate on the portion of the NRPC 
corporate database that directly concerns the Ready Reserve 
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(SELRES) that fall under the jurisdiction of the Commander, 
Naval Reserve Forces for training and mobilization. 

B. HISTORY OF IMAFMIS 

The master files for all Naval Reserve personnel, as 
previously stated, are maintained by the Commander, Naval 
Reserve Personnel Center in New Orleans, LA. However, until 
April 1989, the ADP management for these records, files and 
recently converted database was the responsibility of the 
Naval Military Personnel Command, NMPC-9, Director/Special 
Assistant for Naval Reserve Matters (with dual responsibility 
as OP-OIR). This office, located in Washington, DC and 
physically separate from NRPC, is the command responsible for 
running the system. 

IMAPMIS today is a conglomeration of smaller systems whose 
origins can be traced back to the Naval District organization. 
Its functionality has evolved minimally since its inception 
in the mid-1970s at the Naval Training Center in Bainbridge, 
MD. However, its efficiency has diminished significantly as 
the system has migrated through seven different hardware 
suites during its lifetime. Initially a batch-oriented 
sequential file, tape system fed by punched cards, IMAPMIS was 
designed to update Naval Reserve personnel data on a monthly 
basis emd to report mobilization billet requirements on a 
quarterly basis. As recently as 1981, the data collected at 
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NRPC was sent to Washington, DC where it was processed on the 
OP-01 nalnfraae computer. Due to the massive volume of 
approximately 750,000 records, a typical monthly update run 
required a minimum of seven days to process. The quarterly 
mobilization requirement file updates from active duty inputs 
required em additional 25 hours of processing time (IMAPMIS 
SDP 1,1983). Any errors identified during the monthly 
processing were returned to the local Naval Reserve Activity 
(NRA) for correction. The monthly processing schedule caused 
inordinate time delays in error detection and correction, and 
could prevent a SELRES from receiving drill pay for two to 
three months. Another significant problem involved accurate 
identification of current mobilization billets. SELRES 
Personnel Mobilization Teams (PMT), who are responsible for 
the initial mobilization of Naval Reserve IRR assets, found 
it impossible to accurately identify valid billets. At any 
given time, the mobilization billet listings available to the 
PERSMOB Teams could be three months old and created confusion 
resulting from inaccurate readiness information during recall 
and mobilization exercises. 

In regard to the state of IMAPMIS in 1981 and its impact 
on the SELRES and NRPC: 

The Naval Reserve Personnel Center cannot properly perform 
its mission with regard to maintenance of current, 
accurate, timely personnel files, support for 
mobilization, or provision of scheduled and ad hoc reports 
to DOD emd DON users. The monthly update cycle provides 
data which is in a range of 45 - 65 days old by the time 
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the information is available to users. In case of data 
exceptions a minimum of an additional 30 days must be 
added. As a result ... managers of Inactive Personnel 
will continue to make major management and policy 
decisions based on inaccurate, invalid and non-current 
information or no information at all. (IMAPMIS MENS, 1981) 

In October 1981, out of desperation, the Chairman of the 
National Naval Reserve Policy Board specifically addressed the 
shortfalls of IMAPMIS in a memorandiun (NNRPCB Memo,October 
1981} to the Chief of Naval Operations. He complained of the 
overall "inadequacy of computer support for Naval Reserve 
manpower and personnel administration." The memo requested 
corrective actions be undertaken immediately to alleviate the 
inability of the Naval Reserve to quickly restructure Selected 
Reserve Mobilization billets among Naval Reserve Activities 
to match changes implemented by active duty commands. This 
problem directly contributed to improper structuring of 
Reserve Units and often reflected a misrepresentation of the 
training levels of personnel assigned to these units. 

A second Immediate problem addressed in the memo concerned 
the inadequacy of IMAPMIS to maintain accurate personnel 
records and its inability to provide fast accurate drill 
reporting error feedback to NRAs. The memo proposed that if 
errors were detected early and information provided to tho. 
activities, corrections could be submitted prior to the actual 
data transfer to the Naval Finance Center, Cleveland, OH. 
This would significantly enhance the generation of accurate 
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and timely ACDUTRA emd monthly drill pay. In the existing 
environment, errors in drill reporting were not detected until 
the data tapes were processed on hardware physically located 
in Bratenol, OH emd resulted in inordinate delays in 
processing pay checks. 

As a result of repeated complaints of this nature, it was 
decided that IMAPMIS should be redesigned and converted from 
the archaic batch, tremsaction-orlented system to a relational 
data base management system (DBMS). The Mission Element Needs 
Statement (HENS) for the conversion of IMAPMIS was submitted 
on 15 July 1981 by NMPC-92, and the first version of the new 
relational database was put on line in April 1989. The 
IMAPMIS redesign effort, starting with Milestone 0 approval 
in September 1981, was followed by Milestone I approval in 
Jemuary 1983, emd Milestone II approval in Jemuary 1989. The 
"redesign" as it is commonly referred to, did not modify or 
enhance the operations, interfaces or functionality of 
IMAPMIS, but merely transposed the flat file batch records 
into a relational database. Meanwhile, over the 9 years of 
development and transition, requirements for IMAPMIS to 
provide more accurate and timely Information, and needs for 
ad hoc management reports have grown exponentially. Future 
emtlcipated reporting requirements of IMAPMIS also indicate 
that the system, already taxed beyond its cap 2 d>ilitles, will 
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soon be tmable to provide even the most basic requirements of 
the Commander, Naval Reserve Force. 

Over a span of the past twenty years, IMAPMIS has been 
shuffled from one computer hardware suite to another without 
any effort to redesign or develop new functionality capable 
of tzUcing advantage of Increasingly sophisticated hardware 
and software environments. Simultaneously, internal and 
external demands and requirements for timely, accurate, up- 
to-date Information have increased significantly. Yet the 
"redesigned" IMAPMIS remains an archaic system that does not 
meet the current requirements of today's fast-paced world and 
need for ad hoc management reports. Problems abound with the 
accuracy of reserve unit structure, personnel records and the 
drill reporting system that authorizes SELRES pay. Inputs to 
IMAPMIS are still designed around a flat-file diary entry 
mentality and data tapes are bulk data transferred for 
relatively low priority bi-monthly, processing on the hardware 
at the Consolidated Data Center (CDC) in Bratenol, OH. 
Converting IMAPMIS to a relational database resulted in only 
limited improvements in processing times. However without 
functional enhancements to help managers keep pace with the 
most urgent requirements, IMAPMIS performance has degraded to 
a level considered totally unacceptable to the Commander, 
Naval Reserve Force. (CNRF letter,? November 1989) (CNRF 
letter,10 November 1989) 
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IMAPMIS was then emd is now an antiquated, inefficient 
system imresponsive to user requirements. The goal of this 
thesis is to examine the specific problems encountered by CNRF 
in using IMAPMIS as its corporate database, and then 
subsequently to explore the feasibility of creating a separ¬ 
ate SELRES database controlled by CNRF for SELRES. It is 
proposed that this new database may help streamline the 
existent data flow architectures and eliminate unnecessary 
data passing and duplicate edit checks among systems. 
Finally, it will provide a comparison of the advantages and 
disadvantages of each system from the CNRF and SELRES 
perspective. 
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II. FUNCTIONAL AND OPERATIONAL DESCRIPTION OF HIAPMIS 


As a system, INAPMIS is a highly complex entity that is 
interdependent on other systems and inter-organizational by 
nature. It exchemges, passes and processes data that crosses 
both functional and organizational botmdaries. IMAPMIS 
supports all six categories of Naval Reserve personnel 
discussed in chapter I. It involves the collection, proces¬ 
sing, maintenance and dissemination of all data regarding 
Inactive Naval Reserve personnel. It is described as: 

...the official source of all Inactive Reserve Personnel 
information and, as such, ...is central to all other 
Reserve Component application modules which either pass 
data to it or receive data from it, or both. Addition¬ 
ally, it is responsible for providing key personnel and 
drill attendance data to the Navy Finance Center, Cleve¬ 
land for financial accounting purposes and a total monthly 
personnel extract to DOD. All official inactive personnel 
and drill transactions must flow into the IMAPMIS system 
and all scheduled or ad hoc reports or file extracts are 
generated from it. (IMAPMIS MENS,1981) 

With such a large and varied population to support, the 

functional requirements of IMAPMIS are complex and differ 

greatly according to the personnel category being supported. 

In this chapter, the functions of the IMAPMIS will be 
delineated emd the individual command relationships and their 
respective responsibilities discussed. This will be followed 
by a synopsis of the memy systems, subsystems and files 
belonging to IMAPMIS. Additionally, the major inputs, outputs 
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and overall system data flow architecture and INAPMIS 
interfaces with other systems will be examined. The final 
section of the chapter will discuss some of the more 
significant shortfalls, and the impact that these problems 
impose on the SELRES commvinity and CNRF will be discussed. 
The first aspect of IMAPMIS that will be addressed Involves 
the system fvinctionality. 

A. IMAFMIS FONCTIONALITY 

IMAPMIS provides many functions for Inactive Naval Reserve 
Personnel, as well as for external commands such as the 
Director of Naval Reserve (OP-095), CNRF, OPNAV, NRPC. In 
many ways, it replicates or mirrors similar active duty 
systems, particularly in respect to personnel data collection, 
processing and information storage. However, IMAPMIS is 
tasked with many additional functions that, within the active 
duty environment are performed by separate commands with 
independent systems. The conglomeration of these disparate 
functions into a single monolithic system, have made IMAPMIS 
a highly complex entity where organization responsibilities 
are vague and difficult to trace. It is even more difficult 
to ascertain the exact origin of data elements or the source 
of data errors. The result is a system that essentially runs 
the users rather than allowing the users to run the system or 
a prime exeunple of the tail wagging the dog. 
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From a general perspective, IMAPMIS is comprised of 
essentially four major fvinctions. These may be further 
subdivided for better understanding, however they are prima¬ 
rily related to: 

1. Mobilization Billet information. Reserve Unit Billet 
Structures, and SELRES assignments to billets 

2. SELRES drill and ACDUTRA participation data capture 
and storage 

3. Personnel records and data update, and 

4. Transfer of personnel data between active and inactive 
personnel systems 

The primary objective of IMAPMIS is to manage the Naval 
Reserve database. This database, the official source of all 
Naval Reserve personnel data is a major subcomponent of the 
NMPC Manpower, Personnel and Training Information System 
(MAPTIS) and contains critical data concerning both 
mobilization billets and the Inactive Naval Reserves who will 
fill them. Although it supports all categories of reserve 
personnel, this chapter will focus on functions that are 
specific to the SELRES community. 

Interestingly, SELRES personnel comprise only edsout 18% 
of the total Inactive Reserve population, yet transactions 
supporting SELRES personnel account for an overwhelming 
majority of data inputs and updates at and through NRPC. A 
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check of NRPC manual transaction logs revealed that during the 
month of September 1989 approximately 60,000 transactions were 
hand-keyed updating IMAPMIS. Of these transactions, over 65% 
were estimated to pertain to SELRES. 

1. Mobilization Billet Requirements 

Perhaps the single most important function of IMAPMIS 
is to provide the Commander, Naval Reserve Force (CNRF) with 
current, frequent updates of reserve billet requirements. 
Once the billet requirements are generated on RUMAS and 
printouts are provided to CNRF, they are then used to 
structure these billets into Naval Reserve Units to which 
SEIiRES personnel will be assigned. Training requirements are 
est2Q3lished with the ultimate goal of being able to provide 
adequate numbers of pre-trained SELRES personnel to fill 
active duty billets in the event of mobilization. Current and 
accurate reporting of active duty requirements enhances the 
ability of CNRF to properly structure Reserve Units among its 
417 training sites and its ability to provided for the most 
efficient use of both training and personnel resources. 
IMAPMIS, by functional description must be capable of allowing 
preassignment of over 200,000 SELRES within an environment 
where over half of these assignments normally change over a 
three-year period. In the event of mobilization, IMAPMIS 
should also support the assignment and activation of 
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approximately 30,000 personnel in the course of any single 
week. 

2. Individual Participation Credit 

Another major function of IMAPMIS is to collect and 
maintain all Inactive Naval Reserve participation data. The 
total number of points that each individual officer earns and 
the reason they were awarded is collected and summarized on 
annual basis. (Enlisted data are still recorded manually and 
plans are to incorporate this function in phase two of the 
IMT^MIS redesign.) The reservist's anniversary date is used 
as the basis for this point capture. The summation of these 
points determines the members retirement eligibility. Points 
are earned for drill completions, Acti\e Duty for Training 
(ACDUTRA) completion, credit for completion of training 
courses and credit for any pre-reserve or other extended 
periods of active duty. NRPC is responsible for accurate and 
timely update of individual SELRES participation and 
retirement points as well as maintaining current point 
captures for all Inactive Naval Reservists. These point 
totals and certification of retirement eligibility are passed 
to the Navy Pay and Personnel System (PAYPERS) and NFC for 
disbursement of retirement pay. 

A function parallel to tracking the ACDUTRA and drill 
participation for SELRES provides accounting and financial 
data status to OP-095 for the purpose of managing the Reserve 


19 






Personnel Navy (RPN) appropriation. The annual RPN 
appropriation is the allowance of funds from which SELRES and 
active duty support personnel are paid. The total 
expenditures must be monitored closely by OP-095 to preclude 
exceeding congressionally mandated authorization levels. 

3. Personnel Records and Data Update 

IMAPMIS serves as the master repository of all 
Inactive Naval Reserve personnel data (service and medical 
records). In this capacity, NRPC is tasked with maintaining 
and updating this data as well as providing collected data to 
external systems in pre-programmed and limited ad hoc formats. 
Critical data items such as officer promotional status, 
individual drill status, paygrade/rank information and current 
address files are maintained. Other important elements such 
as names of beneficiaries, and next of kin are maintained. 
It is vital that members' personnel data are correct and 
updated in a timely manner. Errors can drastically affect 
reported strengths, training levels and SELRES pay. 

4. Data Transfer 

Finally, IMAPMIS allows for the transfer of personnel 
data to and from active duty systems. Through data updates 
from NMPC, IMAPMIS and NRPC receive records of individuals who 
are being released from active duty emd transferred to the 
Inactive Naval Reserve. Conversely, IMAPMIS must also provide 
personnel records and data to active duty systems for 
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personnel who either terminate their reserve commitments and 
return to active duty or are recalled for extended periods of 
active duty. This particular functionality will become 
critical in the event of mobilization where massive numbers 
of personnel records must update active duty systems. Errors 
in data will adversely affect mobilization. 

It is estimated that IMAPMIS generates approximately 433 
cyclical reports and is relied upon as the sole source of 
support for over 500 non-standard, ad hoc management inquiries 
per year. The capability to expand IMAPMIS in order to 
satisfy ever-increasing demands in compliance with DOD and 
Congressional information demands is severely limited. 
Improvements to IMAPMIS anticipated in the follow-on stages 
of the redesign project include a review of all system outputs 
and output methods. All existing programs will be replaced 
by new applications and em enlisted automated participation 
point capture system will be developed. (IMAPMIS SDP 111,1989) 

However, the conversion project to date has exceeded cost 

projections by $1,589,761 and: 

When compared to the schedule provided...it is apparent 
that this project fell well behind projections. This 
reflects funding limitations, restrictions placed on the 
AOP project m 2 uiager by unforseen and unforeseeable even¬ 
ts, procurement delays, and, to some degree over-op¬ 
timistic projections. (IMAPMIS SDP 111,1989) 

Additionally, SELRES constitute only 33% of the total 
record maintenance responsibility of IMAPMIS and error 
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corrections and updates account for over 17% of all data 
inputs to IMAPMIS. This reflects a tremendous manpower 
requirement for input of data. Development of new programs 
that will support interactive input update is only one of many 
high-priority enhancements required for future development. 
In the present environment of budget reductions and the 
intense congressional interest in large centralized Automatic 
Data Processing (ADP) and software development projects it is 
uncertain when or even if these enhancements will be approved 
and become operational. 

B. COMMAND RELATIONSHIPS AND RESPONSIBILITIES 

In addition to having a firm grasp of the overall 
functionality of IMAPMIS, one must also understand the 
interoperability and complex inter-command relationships and 
responsibilities associated with IMAPMIS. To actually support 
the previously discussed processes, IMAPMIS must provide 
operational Interfaces, either direct or indirect, with 
internal and external systems. These interfaces create unique 
and often conflicting requirements within the system. It is 
almost impossible to ascertain the origin of a data element 
or produce an audit trail depicting the location and time of 
the most recent update. As can be imagined, "The problem of 
maintaining high quality records in an information system is 
magnified in an inter-organizational computer system." 
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(Laudon,January 1986). The sane data may be used for several 
different purposes at differing management levels. The 
quality and timeliness of the data also differs among the 
users, making it virtually impossible to specifically define 
the requirements of the system. Many of the processes that 
generate information and reports use inputs that are outputs 
from other processes. Subsequently, errors in the original 
data items may be altered, modified and further corrupted. 

The following sections list the major command relation¬ 
ships of IMAPMIS along with a very brief synopsis of the 
Information/data required by each and at what level and manner 
the data is used. As can be seen, the levels of interaction 
2 Uid type of data provided among these systems varies 
dramatically. Figure 2 provides an overall view of the 
individual commands and organizations that depend on or 
utilize IMAPMIS data. 

1. Chief of Naval Personnel (OP-01) - Washington, DC 
The Deputy Chief of Naval Operations (Manpower, 
Personnel and Training) provides ADP hardware, software and 
facilities in Washington, DC in support for IMAPMIS. A 
subordinate code, OP-16 is also responsible for establishing 
and enforcing data element emd Navy Live Cycle Management 
stemdards. 
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Figure 2. Coounand Hierarchy 
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2. Chief of Naval Operations (OP-095) - Nashii.^ton, DC 
The Director of Naval Reserve, under the direction of 

the Chief of Naval Operations, provides periodic compilations 
of mobilization billet requirements to IMAPMIS. This billet 
data is passed to IMAPMIS from NMDAS at OPNAV. IMAPMIS would 
then generate hard copy reports that were delivered to the 
Commander, Naval Reserve Force headquarters for the purpose 
of determining the manpower structure of the reserve units. 
This relationship is expected to change in June of 1990 and 
the billet data will be provided directly from OPNAV's NMDAS 
system to CNRF's new Reserve Training Support System (RTSS) 
through direct interface. 

3. Naval Military Personnel Command - Washington, DC 
Naval Military Personnel Command (NMPC) establishes, 

implements and administers policies for assignment, retention, 
separation and discharge of inactive Naval Reservists. These 
functions are accomplished through direct liaison with its 
subordinate command, NRPC and indirectly with OP-095 and CNRF. 
NMPC provides personnel data to IMAPMIS through the Officer 
Personnel Information System (OPINS) and the Naval Enlisted 
System (NES) and the Source Data System (SDS). Additionally, 
NMPC-9/OP-01R requires access to IMAPMIS to determine officer 
promotion history and eligibility using the Inactive Officer 
Promotion Administrative System (lOPAS). In this 
relationship, NMPC-9, the inactive reserve counterpart to 
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NMPC-2 for active duty personnel, convenes all reserve officer 
promotion boards and updates officer promotional status at the 
conclusion of each board using the Inactive Officer 
Administrative Promotion System (lOPAS). It is imperative 
that IHAPMIS reflect accurate data such as date of rank and 
proper designator. Incorrect information may inadvertently 
preclude em otherwise eligible officer from promotion. It is 
equally important that promotion updates entered by NMPC into 
lOPAS properly update the promotional history file. 

4. Naval Reserve Force - New Orleans, LA 

Commander, Naval Reserve Force (CNRF) is responsible 
for structuring Reserve Units from mobilization billet 
requirements provided from NMDAS at OPNAV. Structuring 
billets into units involves accessing total billet require¬ 
ments and matching needs against available SELRES assets. By 
optimizing matches between SELRES assets and billet 
requirements, CNRF can maximize unit manning, enhance train¬ 
ing levels emd Improve unit cohesiveness. The goal is to 
assign as many SELRES to local units as possible and to 
eliminate the need to assign an individual to a xmit in a 
geographical area different them his/her home. Once the units 
are structured, training requirements are established after 
the billets are fed back into IHAPMIS during the next 
processing update. Only after all these steps are completed, 
and after the new unit/structure is reflected on the hardcopy 
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reports from IMAPMIS, can CKRF and local Naval Reserve 
Activities (NRAs) assign SELRES to these billets. 
Presently,the structuring process is completed manually at 
CNRF from billet listings produced by RUMAS. Unit structuring 
is a difficult, time consuming process. Without the aid of 
automatic processing support it is difficult to assess the 
decisions determining unit size, placement and composition. 
The direct data exchange from NMDAS to RTSS anticipated in 
June 1990 is now in a testing phase. However, it is expected 
that this new interface will significantly expedite Reserve 
Unit billet structuring process. Additionally, a new decision 
support system is being developed for RTSS system that will 
significantly enhance the structuring process. As a result, 
CNRF should be able to make far better decisions regarding 
unit placement and manpower composition than can be 
accomplished with the manual procedures necessary with 
IMAPMIS. 

An equally important responsibility of CNRF is to 
effectively train and administer the SELRES community in 
preparation for mobilization. Once the reserve xinlts are 
structured and memned, it is necessary to monitor the level 
of manning emd quality of training completed within those 
units. Units are assigned training and readiness status based 
on these training achievements and Individual unit manning 
levels. This data is used both Internally for planning and 
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evaluation purposes as well as externally for overall force 
status reports. The accuracy of this data is vital to an 
accurate representation of the welfare of the Naval Reserve. 

5. Navy Finance Center - Cleveland, OH 

The focal point for active duty navy personnel 
financial processing, the Navy Finemce Center (NFC) also 
accounts for all drill, ACDUTRA and retirement pay, based on 
drill and personnel data passed from IHAPMIS. Concurrent with 
the decision to redesign IMAPMIS in 1982, it was determined 
that the main IMAPMIS processes would be run on the CDC system 
that supports NFC, thus allowing the consolidation of all pay 
processing for both active duty and reserves on a single 
system. Necessarily, this command relationship is critical 
for SELRES and retired reserves. Although few data changes 
may disrupt retired pay, any number of invalid or incorrect 
personnel data elements affect the timely, accurate drill pay 
of SELRES personnel. 

6. Naval Education and Training Center - Pensacola, FL 

The Chief of Naval Education and Training Center 

(CNET) provides results of correspondence course completions 
to IMAPMIS. Completion of these courses by Naval Reservists 
adds to individual accumulations of Reserve Retirement 
Participation Points. Presently, the course completion 
documents are mailed to NRPC where they are hand-keyed into 
IMAPMIS. There is no method to track or validate inputs and 
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it becomes, by default, the individual's responsibility to 
ensure that these points are actually awarded. 

7. Naval Reserve Personnel Center - New Orleems, lA 

Naval Reserve Personnel Center (NRPC), a field command 
of NMPC, is responsible for maintaining the corporate 
personnel data base of Inactive Naval Reserve Personnel for 
NMPC. This includes total management and assignment 
responsibility for all Pre-trained Individual Mobilization 
(PIM) assets (IRR personnel, standby reserves, fleet reserves, 
and retirees). These personnel assets are totally independent 
of CNRF and do not actively participate in monthly training 
drills. NRPC is Solely responsible to NMPC for maintenance 
of service records and personnel data. 

In addition to PIM administration, NRPC is also tasked 
with the production and distribution of reserve billet 
requirement, mempower and personnel reports. To support these 
reporting requirements, NRPC updates personnel data from and 
for both PIM assets and SELRES. 

C. IMAPMIS SYSTEMS, SUBSYSTEMS AND FILES 

Within IMAPMIS are several major subsystems and file 
applications that support the functionality and command 
relationships described above. A brief description of these 
subsystems, shown in Figure 3, is provided in the following 
sections. 
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1. Inactive File Naintenemce System (IFIUCAN) 

IFILMAN is the central processing system in IMAPMIS 
and actually produces the updated files and reports. It 
accepts data generated by NMPC, OPNAV, NRPC, CNRF and reserve 
field units. When processing runs are made, all input data 
is pre-edited. These edits checks are predominantly for valid 
change codes, postal addresses and zipcodes and designators. 
One estimate reflected a monthly average of 200,000 data 
element updates to personnel records and for approximately 
300,000 drills (IMAPMIS SDP 1,1983). Additionally, IFILMAN 
processes and matches this data against mobilization billet 
files. Rejected transactions are returned to NRPC while valid 
transactions update the IMAPMIS master files. 

2. Reserve Unit Manpower Assignment System (RUMAS) 

CNRF and NRAs use RUMAS outputs to manage the proper 

mobilization billet assignments of SELRES. After units are 
authorized and established by OP-095, the units are structured 
by CNRF and the billets are filled by SELRES. The 
mobilization files include billet requirement data such as: 
the rank or rate, rating and applicable NOBC or NEC of 
personnel that can be assigned to each individual billet, the 
actual structure of each reserve unit and which individuals 
are actually assigned to those units/billets. Billets that 
are designated to be manned from 30 to 90 days after initial 
recall (M+1 to N+3 designated billets) are filled by IRR, 
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standby reserves, fleet reserves and retirees. These 
assignments are managed by NRPC. Immediate mobilization 
billets are managed by CNRF and manned by predominantly SELRES 
assets. RUMAS accepts billet input from NMDAS, and in 
addition to producing unit reports, compared actual 
assignments against valid billets. The principle outputs of 
RUMAS assist OP-095, NMPC, CNRF and NRPC in effective 
management of reserve personnel to effectively support active 
duty mobilization requirements. 

3. Inactive Remote Inquiry System (IRIS) 

IRIS is a pseudo real-time update capability that 
provides data from the Inactive Officer and Inactive Enlisted 
Master files. It allows limited update capabilities for 
specific data elements. Most updates apply to Pretrained 
Individual Mobilization Manpower assets (PIMMs), the NRPC 
managed personnel pool. The system is processed on EPMAC 
hardware in New Orleans, LA and accepts hand-keyed transaction 
entered through NRPC, NFC and NMPC terminals. Data tapes are 
generated from the updates and are used during the next 
periodic IMAPMIS process to update master files. 

4. Navy Enlisted and Officer Retirement Point Recording 
System (NEOPS) 

The system that captures and accumulates Naval 
Reservist credit accrued for completion of drills, ACDUTRA, 
active duty and completion of Correspondence Courses is called 
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NEOPS. The recording and update of these points are essential 
to reservists. Members of the Inactive Naval Reserve must 
accrue adequate points for each anniversary year they 
participate in the reserves in order to obtain credit for a 
"good year". In order to satisfy the requirements for a 
Certification of Eligibility for retirement and authorization 
for retirement pay, a reservist must have completed 20 years 
of satisfactory service. The points are accrued from active 
duty participation, drill participation, fulfillment of annual 
ACDUTRA requirements, and completion of navy training courses. 

5. Inactive Officer Promotion Administrative System 
(lOPAS) 

lOPAS is operated and updated by NMPC-93C, Reserve 
Officer Promotions, and provides up-to-date promotional 
history of officers in the Naval Reserve. lOPAS provides the 
capability to update officer status, such as changes from 
active to inactive service and maintains the inactive officer 
precedence order. In addition, it provides lists used to 
determine eligibility zones for promotion boards and is used 
to generate ALNAV messages indicating promotion selections. 
The lOPAS subsystem also has on-line terminals from which the 
transaction updates produce another data tape. 
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6. Pretxained Individual Mampower Nanageoient Systea 
(PnfMS) 

Updates pertaining to Inactive Naval Reservists 
mfuiaged by NRPC use the PIMMS subsystem. PIMMS is essentially 
independent of IMAPMIS even though the inputs are keyed by 
NRPC personnel and the transaction data tapes are merged into 
IMAPMIS master files during processing. It is primarily used 
for career counseling and individual support of NRPC personnel 
assets and pertains mostly to non-SELR£S applications. The 
on-line data is provided from extracts of the IRIS subsystem. 

7. Inactive Officer Master File (lOMF) 

The lOMF mirrors the active duty Officer Master File. 
It acts as the central repository of all Inactive Naval 
Reserve officer personnel data. Data may be entered into the 
lOMF from keyed input at NRPC or from many data exchange tapes 
processed in bi-monthly runs. 

8. Inactive Enlisted Neister File (lEMF) 

A complement of the active duty Navy Enlisted System 
(NES), the lEMF stores all data pertaining to Inactive Naval 
Reserve enlisted members. It is similar to the lOMF. 

D. IMAFMIS INPUTS, OUTPUTS AMD INTERFACES 

1. Inputs 

Data is input into IMAPMIS at many different sources 
in many different ways. Some of these sources have on-line. 
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real-time update capability while others are recorded on tape 
for future update processing. Among the major sources of data 
input are the Reserve Field Reporting System (RESFIRST), the 
Reserve Training Support System (RTSS ), and several active 
duty automated information systems including the OMF, NES and 
SOS. 

The data collected from the individual NRAs was, \intil 
mid-1989 submitted entirely through the RESFIRST system. All 
personnel data involving reserve members was typed on OCR 
scannable forms and submitted by mail to NRPC. Even the drill 
chits that indicated participation in monthly training were 
processed on special forms that were mailed directly to NRPC 
where they were scanned. Data tapes were generated with this 
drill information and updates including unit assignments, 
advancements and status changes. If the document could not 
be scanned due to errors, it was returned to the NRA for 
correction. If the document was scannable, but the entries 
were not correct, the errors were not detectable xintil the 
next scheduled processing run. This enormous paper system, 
designed around the old diary entry process was time consiim- 
ing and often documents were lost or damaged. Additionally, 
many errors were not discovered for weeks. Once the system 
was updated some errors were detected and filtered through the 
system, eventually reaching the NRA for correction. However, 
the most frequent means by which NRAs were apprised of errors 
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resulted when the reserve member received a check for an 
incorrect amount of pay, or did not receive a check at all. 

As recently as April 1989, CNRF has brought the 
Reserve Standard Training, Administrative and Readiness 
Support System (RSTARS) on line. This system which feeds data 
to RTSS has decentralized data processing and centralized 
control. It is designed for modular applications development 
uses the microcomputers at the individual NRAs for the input 
of reserve data. The data structures, definitions and 
interfaces and edit checks to conform to interface agreements 
formulated with IMAPMIS program managers. RSTARS allows for 
localized data inputs rather than requiring submission of OCR 
paper documents for future scanning. The personnelmen at the 
drill/training sites can now physically key in the data 
updates. Those who use and luiderstand the data now have the 
capability to enter the data. Daily data updates are then 
transferred electronically via modem to the CNRF mainframe on 
a nightly basis. In addition to the built-in standard data 
entry edits, the CNRF processing also validated codes and data 
elements. Tremsaction errors were captured and a complete 
update of rejections was transmitted to the originating NRA 
during the next nightly communication. From the data updates, 
CNRF's RTSS system produces bi-monthly tapes that are to 
submitted to NRPC for IMAPMIS update processing. The data is 
bulk data tremsferred to the PAYPERS system for processing 
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with IMAPMIS. This new automated system improved the 
timeliness of data and reduced the delays inherent to the 
RESFIRST mail-in system. It is anticipated that by the end 
of 1990 all RESFIRST entries to IMAPMIS will be input through 
RSTARS and RTSS. 

This source of data generates a high volume of 
tremsactions, anywhere between 35,000 to over 300,000 
tremsactions per month. RESFIRST was originally scheduled for 
replacement by a Reserve module of Source Data System (SDS) 
that would eliminate the need for OCR diary submissions. 
However, within the last two years, the development of 
Reserve SDS was cancelled. To compensate for this setback, 
RESFIRST is instead being replaced by a CNRF developed RSTARS, 
which was designed around pre-negotiated SDS interfaces and 
data definitions. 

2. Outputs 

System output reports is the largest single product of 
IMAPMIS. Currently, data from IMAPMIS is output in an almost 
countless number of periodic reports that are submitted to 
OPNAV, NMPC, NRPC, Director of Naval Reserve, CNRF eund the 
NRA. The major areas of reporting are personnel support, 
participation support, unit structuring support, 
administrative support and mobilization support. IMAPMIS 
creates approximately 350 tapes per month to support the 
report function and the redesign effort did not Include a 
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requirement to replace these processes, since these reports 
are very structured and many are obsolete, one of the major 
requirements of the current phase of the IMAPMIS redesign is 
to totally review and update all outputs. 

The validity of many of these reports in their present 
form is understandedsly being questioned. Some reports and 
outputs have been determined as useless and are no longer 
being produced. Reserve Unit Assigned Documents (RUADs), 
produced on a monthly basis, should reflect accurate timely 
unit structure data. Many now reflect totally erroneous data. 
In one instance where multiple units and their related billets 
were examined, only one single billet reflected the correct 
rank and rates. (CNRF letter,? November 1989) The 
significance of the data outputs is that IMAPMIS is the 
corporate source, under the auspices of NMPC and NRPC for all 
data relating to the Inactive Naval Reserve. The data 
collected and output by IMAPMIS is a direct reflection on the 
training, manning and readiness levels of the naval reserve. 
If the data is not credible, then the reports are also 
invalid. Managing a system as large as IMAPMIS is difficult 
at best. However, the quality of the naval reserve database 
is severely Inadequate and reflects poorly on the dedicated 
individuals who participate. 
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3. Interfaces 


As can be deduced from the previous pages, IMAPMIS is 
linked in one form or another to numerous internal and 
external systems. To be eUale to accurately transfer data 
among these various systems requires adequate interfaces that 
edit and validate incoming data, without tightly restricting 
data passage. This is a difficult division to meike. 
Historically IMAPMIS has required inordinately tight edits on 
data for reasons that were applicable when the system was 
initially designed. However, many of these edits are no 
longer valid in today's environment (CDR R. Rautenberg, 
October 1989). Since the conversion of IMAPMIS to a database 
did not attempt to redesign the processes or requirements, 
many of these old requirements are still in place and 
functioning and have disruptive effects on all concerned. 
Currently all data is still comprehensively edited whether it 
is received from another automated system or input through 
CRT's. The data is checked for completeness, proper coding 
and data relationships. Other data is validated using 
reference teUsles, logic examinations and comparison to 
personal data already existing in the system. These edits 
were designed for the RESFIRST system rather than new 
relational database. The problem lies herein. If the data 
already contained in the IMAPMIS database is incorrect, then 
the edit checks will not allow the update of some data 
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elements. The problems that these interface constraints 
create is enormous. As previously mentioned, many data tape 
updates are not processed into master file updates on a real 
time basis. For the internal subsystems of IMAPMIS, a data 
element may have been corrected emd a transaction generated 
on the data update tape only to find that weeks later when the 
tape is processed, the transaction may be rejected by an 
interface edit. An example of the complex seunple data flows 
from the NRA to the generation of a SELRES paycheck is shown 
in Figure 4. 

Another of the major external systems with which 
IMAPMIS must interface is the Reserve Component Common 
Personnel Data System (RCCPDS), managed by the Defense 
Manpower Data Center (DMDC) in Monterey, CA. RCCPDS, a DOD 
system that collects Reserve personnel data from all DOD 
systems. 

Through the use of IMAPMIS, the Naval Reserve Personnel 
Center (NRPC) is tasked with maintaining current files on all 
750,000 Inactive Naval Reserve personnel. To accomplish this 
task, IMAPMIS must Interface with many external systems. 
These systems, belonging to other commemds may simply accept 
data from IMAPMIS, pass data to IMAPMIS, or process available 
data. Systems that process data may or may not return updated 
data to IMAPMIS. Among the systems with which IMAPMIS must 
maintain workeUdle Interfaces are the Navy Mempower Data 
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Figure 4. SELRES Pay Data Flows 
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Accounting System (NMDAS) to access mobilization billet 
requirements; all active duty personnel systems such as the 
Officer Master File (OMF) and the Enlisted Master File (EMF); 
the Navy Pay Personnel System (PAYPERS) hardware and software 
for processing drill emd ACDUTRA pay; and DOD Reserve 
Component Common Personnel Data System (RCCPDS) to provide 
periodic and ad hoc reports. The quality of each of these 
interfaces is critical in their own way. CNRF and OP-095, 
responsible for training and readiness of SELRES require 
valid, accurate, up-to-date data on the status of the reserve 
community. The SELRES, who depend on accurate personnel data 
to ensure proper remuneration for reserve participation 
deserve the same accurate, timely transfer and update of data. 
NRPC, tasked with what seems an unmanageable responsibility 
must coordinate and administer a system that reports, accepts 
and processes data from memy internal and external sources. 

E. SHORTFALLS AMD INADEQUACIES OF IMAFMIS 

The Deficiency Statement contained in the initial System 

Decision Paper initiating the redesign of IMAPMIS stated: 

Valid, accurate and current information as well as 
financial data is not being provided to Selected Reserve 
Headquarters and field commands, or to many echelons of 
DON and DOD meunagers. We are not using an effective or 
efficient methods of transferring data between Active and 
Inactive files; mobilization pre-assignments as well as 
assignments at Mob-Day must be made manually emd therefore 
cannot meet mobilization requirements; the NMDAS/RUMAS 
interfaces are totally Inadequate and present numerous 
problems to OP-09R [now OP-095], CNAVRES and Reserve Field 
Commands with regard to incorrect manpower authorization 
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dociments; emd IMAPMIS data elements often do not match 
nor can be directly translated to those required by DOD 
and other users. Therefore, the Naval Reserve Personnel 
Center is not adequately performing its mission of 
providing personnel information support to its many users. 
Because of the age and migration history of the source 
code of IMAPMIS and the lack of documentation thereof, 
minor design changes to the system are attempted only in 
rare and emergency situations. (IMAPMIS SDP 1,1983} 

For the redesign of IMAPMIS, four alternatives were 
considered. The first was to continue with the status quo and 
not change IMAPMIS. The second alternative proposed a single 
interactive project to incorporate all required improvements 
to IMAPMIS. The third alternative, similar to the second, 
used a two-phase approach to improve IMAPMIS. The first phase 
would concentrate on redesigning the lOMF and lEMF and the 
operation to maintain them. The second phase would then build 
on the first phase and eventually improve the entire system. 
The final alternative was a three-phased proposal to first 
update the lOMF and lEMF, then modify output and report 
generations and add an ad hoc query capability and finally, 
the last phase would improve the interfaces between IMAPMIS 
and other external systems. The ultimate decision was to 
select the fourth alternative. During the initial planning 
phase, it was decided to concentrate on converting the 
existing flat file, sequential batch system into a relational 
database. The conversion which began in 1981 did not include 
emy significant functional enhancements, allow development of 
the proposed ad hoc query capedsility, improve any of the 
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output/reporting formats, or improve any of the external and 
internal interfaces of IMAPMIS. With the new database being 
placed on-line and fxinctioning in April 1989, the system is 
somewhat faster than the old version and some basic inquiries 
are more efficient. However, the inadequacies of the 
interfaces and the inability of IMAPMIS to provide OP-095 and 
CNRF with up-to-date, accurate information regarding Selected 
Reserves still exist. The first of the three phases took two 
years longer thaui the originally projected life cycle. Al¬ 
though new enhancements to IMAPMIS are being considered under 
phase two to improve these functions, other factors are 
draining resources. In an environment where data access, 
processing and utilization is paramount, government officials 
demand up to date information when making crucial decisions 
Involving the Armed Forces. As the repository for all Naval 
Reserve personnel information, being able to provide accurate 
and timely data is rapidly becoming a major concern and 
priority for IMAPMIS managers and system planners. 

Although improvements are essential, NRPC is 
responsible for providing information on all Naval Reserves. 
Selected Reservists comprise approximately 131,000 of the 
750,000 records maintained by NRPC. However, this relatively 
small percentage of records generates a large percentage of 


NRPC workload. 






It is important to recall the importance of the SELRES 
who comprise the backbone of the Naval Reserve. They 
represent the best trained, immediately mobilizable assets 
available to the Navy. Taking into account the multitude of 
conflicting priorities and pressures on NRPC, it is still 
necessary to remember that SELRES are vital resources and 
their needs must be addressed. Nothing more seriously affects 
SELRES retention, training levels and morale than the 
continued loss of or incorrect pay. 

1. Mobilization Billet Structuring Problems 

As discussed earlier in the chapter, updated 
mobilization billet requirements, reported through NMDAS, are 
essential to CNRF. Responsible for effective training of 
SELRES, CNRF^s function is to structure these billets into 
individual reserve units at NRAs throughout the United States. 
The billets were passed through IMAPMIS to CNRF where they 
were manually manipulated into units. Without any computer 
aided support, it was a slow difficult process that usually 
did not yield the optimum unit structures. However, the CNRF 
computer department concurrently designed a limited decision 
support system (DSS) for helping the structuring process and 
is in the process of developing this application. After many 
years of discussion CNRF was finally authorized a direct 
interface with NMDAS to obtain the billet data through RTSS 
rather than passing data through IMAPMIS and waiting on 
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scheduled processing. This improvement, which is approved for 
June 1990 implementation will significantly improve the 
timeliness of data received by CNRF and with the DSS should 
prove to enhance overall unit structuring efforts. However, 
problems still exist in IMAPMIS where units that have been 
dissolved are still carried in the database. This happens 
because IMAPMIS defaults will not allow deletion of a unit 
vuitil all assigned personnel are transferred out of the unit. 
If the individual transfer transaction is not accepted by 
IMAPMIS, the member will remain assigned to the unit and the 
unit will continue to be reflected long after being 
disestablished. 

2. Interface Problems 

The IMAPMIS interfaces as they exist today are totally 
inadequate to support the day to day data requirements of 
NRPC. A good illustration of interface problems involves an 
active duty member being released and transferred to the Naval 
Reserve. Although NES and SDS are updated to reflect the loss 
of the member and release orders are generated, IMAPMIS and 
NRPC are completely unaware of the pending gain to the Naval 
Reserve until the point in time that the individual's service 
record physically arrives in the NRPC mail room. Since 
IMAPMIS theoretically interfaces with NES and SDS, this data 
and the individual's service record information should be 
automatically transferred and a flag should be generated for 


46 




NRPC to expect the service record. In actuality, when the 
record is received at NRPC, it is screened manually for 
pertinent data items including a Reserve contract commitment 
and the member's current address. Exacerbating the 
frustration, the data, up to 19 fields, is hand-scribed onto 
a data input form that is later given to an operator who 
physically hand-keys the data into IMAPMIS. This initial 
input actually establishes the individual as a member of the 
Naval Reserve community. Without this data entry, the 
individual will not be reflected in the main IMAPMIS database 
regardless of his status in NES and SDS, and he/she cannot 
affiliate with a Reserve unit, participate in any reserve 
functions or receive any pay. The problem is further 
compounded when an individual is released from active duty 
and subsequently reports to the closest reserve activity to 
affiliate with a unit. The proper diary entries are made and 
submitted, but will be automatically rejected several weeks 
later when the system is updated since there is no record of 
the individual in the database. Interestingly enough, the 
active duty Officer Master File (OMF) and Enlisted Master File 
(EMF) were designed and completed by different contractors. 
Subsequently, the interfaces between these two systems and 
IMAPMIS are totally different. For officers, as an example, 
IMAPMIS does receive indications of losses from active duty 
and pending gains. However, similar types of data must be 
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hand-keyed into IMAPHIS after a physical screen of the 
officer's record. Dviring a recent visit to NRPC, it was noted 
that operators were using Officer Data Cards (ODCs) generated 
by NMPC to input officer Naval Occupational Billet Codes 
(NOBCs) and Additional Qualification Designators (AQDs). 

In addition to RESFIRST diary entry inputs, IMAPMIS 
now allows a bi-monthly update from CNRF RTSS system. The 
RTSS system is updated daily from a majority of the NRAs, thus 
maintaining a reasonably current, accurate database. Limited 
edit checks are built into the initial data capture at the 
activities, however, extensive edits are performed on uploaded 
data to ensure validity. When these checks reject data or 
inputs, the svibmitting reserve activity is aware of the 
problem the following working day. (Schwartz,October 
1989,p.49) However, problems have surfaced with the interface 
with IMAPMIS. The RTSS database, a valid, accurate database 
is uploaded daily. Conversely, IMAPMIS is updated during bi¬ 
monthly processing runs and lags significantly behind RTSS. 
Within IMAPMIS there are numerous duplications of edit checks 
already performed in RTSS and additional edit checks that have 
little relevance on the data input. These edits routinely 
reject emd override otherwise valid transactions obtained 
directly from the SELRES emd input at the NRAs. These 
interface problems were specifically addressed by CNRF in 
correspondence to NRPC explicitly stating their frustrations 
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in attempting to analyze rejected transactions created in the 
interface of IMAPMIS and RTSS. The letter indicated that NRPC 
was not providing satisfactory support in attempting to 
identifying why transactions were being rejected from IMAPMIS. 
The CNRF perspective focused on the fact that there seemed "to 
be no effort to analyze refections to ensure they should in 
fact, be rejected." (CNRF letter,November 1989). In addition 
to data quality and SELRES pay problems, this perceived lack 
of responsiveness on the part of NRPC further strained the 
relationship between CNRF and NRPC. However, with the 
enormous workload at NRPC, the response is more likely 
attributable to trying to support too many priorities with 
sadly inadequate resources. 

3. Design Problems 

Still another problem within IMAPMIS involves the flat 
file mentality of the RESFIRST diary entry system. The diary 
entry was developed to provide numerous pieces of data 
collectively in a prescribed order and format for efficient 
update. Since the system was designed for batch, sequential 
processing, all data items had to be updated on a single pass, 
thus requiring that multiple data entries, in predefined 
formats. The entry was submitted on special forms typed in 
OCR fonts, and mailed in special envelopes to NRPC. There, 
the forms were hand-fed into optical scanners and data tapes 
were produced for later merging with the IMAPMIS database. 
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Few errors were detected upon scanning and most remained on 
the tape unidentified until processing, weeks later. 

Within the RESFIRST diary input system, there were 
many transactions that were a series of entries "bundled" 
together. Multiple entries were required for a single 
personnel status ch 2 mge. A good example is a simple 
advancement. The change in status required two separate diary 
entries: the first for discharge of the member and is followed 
by an adveincement entry. If these entries are in the wrong 
sequence or the discharge entry is omitted or erroneous, the 
advancement will not be recorded and the member will only be 
paid at the previous rate. Similarly, if an individual is 
transferred from one vmit to another, an entry must first 
appear to show the individual as a loss to the original \inlt. 
This must then be followed by an entry for a personnel gain 
to the ultimate unit. Again, before the member can be 
properly assigned to the new iinit, both of these entries must 
be made in the proper order. The normal sequence of events 
is such that the individual reports to the new unit the 
following drill period and a drill chit is processed and 
submitted. However, IMAPMIS still holds the member in the old 
unit. Not only is the drill chit rejected, disallowing the 
member's pay and participation credit, it also reflects that 
the member has missed a drill period at his authorized unit. 
Numerous other examples exist of these "bundled" transactions. 
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They all create major problems for the SELRES members and the 
NRA staffs that support them. Such problems as these tend to 
generate even more problems and inaccurate data throughout 
IHAPMIS. For example, a billet at the new unit is still 
unfilled according to IMAPMIS and it is possible that another 
member may be assigned. Conversely filled, the billet is 
shown as being vacemt and detracts from the manning, readiness 
and training status of the iinit. The individual is not 
receiving credit or pay for participation. Such problems may 
tedce anywhere from 45 to 90 days to correct. It is obvious 
that problems of this kind have a major waterfall effect and 
result in incorrect information concerning manning and 
training levels of SELRES. 

4. Parallel Processing Problems 

Expanding on the frustrations encountered with 
problems of "bundled" transactions, another significemt 
processing problem was discovered after the database 
conversion was completed. It was noted that many of these 
"bundled" transactions w e being totally rejected from 
IHAPMIS processing runs. Only after months of research was 
it discovered that, by implementing a parallel processing 
capability to run IMAPMIS, the second or new data entry was 
often processed before the initial entry. Therefore, the 
system attempted to process the second entry before the first. 
This resulted in this specific transaction being rejected. 
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Subsequently, when the first transaction was processed, there 
was no second transaction to update the first. As can be 
imagined, the results were disastrous. Examples Included 
advancement transactions where the individual advancement was 
processed before the discharge transaction. These 
transactions were immediately rejected due to the lack of a 
discharge entry. Next, when the discharge transaction ran, 
the individual was automatically discharged. Since the 
advancement transaction had already been rejected, the 
individual was then reflected in IMAPMIS as being discharged. 
Here again, the individual could not receive pay for drill or 
participation credit until the master database was updated. 
Support staff at the NBAs continued submitting the same 
entries, but were unable to correct the member's status. The 
resolution of this single problem took in excess of three 
months to identify and many Instances still remain unresolved. 
Meanwhile unit strength codes were Incorrect and members were 
not being properly paid. 

5. Strength Code Problems 

Within RESFIRST, SELRES are assigned strength codes to 
indicate the location of their service record and drill site. 
Since SELRES move frequently without transfer orders like 
active duty personnel, a system of tracking the member and 
his/her respective service record was essential. To do this, 
strength codes were devised. If the member and service record 
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were held by the same NRA, the strength code was valid emd 
allows processing of personnel status updates. If the record 
and individual were not held by the same NRA, the strength 
code prevented many personnel data updates. If for some 
reason, a SELRES is not properly assigned to a unit, it 
affects an assigned strength code. If this strength code is 
not the proper value, the individual is not allowed, according 
to RESFIRST Manual, to be transferred, be promoted, discharged 
or physically die. 

6. Audit Trail Problems 

Actually affecting all of the previously discussed 

problems, another significant shortcoming of IMAPMIS is the 

lack of 2 my audit trail for tremsactions. In the previous 

cases cited, there was no way to quickly identify problem 

trends. Once the transaction was rejected, it was gone. This 

lack of functionality medces it exceptionally difficult to 

troubleshoot or review for problem trends. A proposed 

solution would be to accept a single entry that would then 

generate the required data for both the first and second 

entries. Audit routines should be embedded into IMAPMIS. 

Most system users are aware that: 

The edit-valldation-update-rej ect-correction-reentry 
process is considered critical...because it determines, 
to a great extent, the reliability of a systems's output. 
Unless handled properly, rejected transaction may be lost 
entirely or never corrected. (Benoit,May 1979,p.26) 
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within IMAPMIS there is no provision for suspense files, 
automated error files or even minimal error messages. Since 
this single problem contributes heavily to others documented 
ed}ove, it should be a high level priority for future 
enhancements to IMAPMIS. 

F. IMPACT OF IMAPNIS SYSTEM SHORTFAUiS 

As is Illustrated in these few exeunples, IMAPMIS is a 
large, unwieldy system, designed around old hardware 
technology and concepts such as diary entries. IMAPMIS is 
inflexible, slow 2 md unresponsive to the needs of today's 
SELRES. The problems enumerated above are primarily related 
to SELRES and represent only a few of an overwhelming number 
of enhancements that are required in IMAPMIS. System 
interfaces affect every reserve category and have serious 
effects on the quality of data reported to external systems 
such as RCCPDS. These erroneous reports generated from poor 
quality data do not accurately reflect manning levels, 
training and readiness status emd overall condition of the 
Naval Reserve Force. The problems associated with "bundled" 
treuisactions must be evaluated and realistic database 
management solutions applied. The entire design of IMAPMIS 
should be evaluated to more clearly identify individual 
command responsibilities euid data ownership. Similarly, the 
possibility of segmenting IMAPMIS into several modular 
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processes divided among the responsible commands may provide 
some solutions. Only after specific responsibilities are 
agreed upon emd inter-orgemizational issues are identified emd 
resolved, can we expect to improve the quality of the IMAPMIS 
data and processes. 

As has been repeatedly observed, IMAPMIS is an unreliable, 
cumbersome emd generally \insatisfactory conglomeration of 
programs emd systems. Data and information, frequently 
reported incorrectly, are used by managers of the Naval 
Reserve and external organizations to evaluate the status of 
the force emd to determine future directions and policies. 
Moreover, the applications do not lend themselves to 
modification or enhancement and more they do not support the 
requirements of either CNRF or MRPC. 

IMAPMIS, a result of automating manual processes and data 
collection, was not intended to and, in its present form, 
cemnot provide the memagerial support required by either NRPC 
or CNRF. 

In spite of these inadequacies, IMAPMIS is still the 
official repository of data concerning the Inactive Naval 
Reserve. The objectives of IMAPMIS redesign, as formulated 
in the early 1980s and listed below, were to correct these 
very problems. IMAPMIS redesign was intended to: 
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1. Support inactive reserve information requirements with 
valid, accurate and timely manpower information 

2. Provide personnel and authorization data for screening 
emd assigning personnel for mobilization 

3. Provide an automated assist in structuring billet 
authorizations into reserve units 

4. Respond to mobilization requirements promptly 

5. Record officer and enlisted reserve participation data 

6. Provide effective and efficient exchcinge of data 
between active and inactive personnel files 

7. Provide personnel data for inactive reserve member 
promotion board support 

However, throughout the redesign effort (1981-1990), IMAPMIS 
functionality has remained stagnant. Not one goal of the SDP 
I has been achieved, and there has been significantly little 
progress toward any of the seven objectives. 

Projections for the redesign of IMAPMIS estimated a total 
life cycle of seven years at a cost of $ 21,773,000 amd a 
completion milestone for phase one in March 1985 (IMAPMIS SDP 
1,1983). Actual spending data for phase I is not available, 
however figures for the period of fiscal years 1983 through 
1986 reflect cost overruns of approximately 1,371,000. After 
nine years, two years longer than the entire projected life 
cycle of all three phases of the development effort, IMAPMIS 
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is still a long way from meeting the requirements specified 
in 1981. The project, as typical of large systems, exceeded 
all cost projections and was embarrassingly years behind 
schedule. 

Considering the reduction in military budgets emd the 
congressional interest in over-budget, over-schedule ADP 
system development (HOR Report 101-121,July 1989), it is 
highly doubtful whether IMAPMIS will ever be able to meet all 
of its functional requirements. Although the core of IMAPMIS 
has successfully been transformed into a relational database, 
the data itself is wrought with errors. The centralized 
control policies emd lack of interface between IMAPMIS system 
developers and end users also reflect traditional batch- 
oriented meuiagement philosophies that have created a virtual 
wall between users in the field emd NRPC. 

Me€uiwhile, throughout the transition from a flat file 
system to relational database, the fvinctional requirements, 
including the need for management reports emd ad hoc queries 
increased significantly. Due to the original design and poor 
documentation of IMAPMIS applications, they cannot be 
modified. Instead, each process must be individually 
examined, redesigned and rewritten to meet the current 
requirements within a datedsase environment. 

Within the redesign effort, the huge number of new 
processes needed to rectify these problems and the extended 
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period of time required to develop them are unacceptable. 
While all of the organizations that use IMAPMIS are aware of 
these Inadequacies, until recently, there has been no 
alternative. 

To continue with the status quo of IMAPMIS will adversely 
affect all aspects of the Naval Reserve, particularly OP-095 
and CNRF in their ability to provide well-trained SELRES. 
Other alternatives should be examined before more resources 
are devoted to IMAPMIS. With the present emphasis on 
downsizing ADP systems and future probabilities of austere 
budget constraints, it is postulated that physically trans¬ 
ferring the SELRES database maintenance responsibilities from 
NRPC could provide a viable solution to all concerned. Since 
RSTARS and RTSS became operational, CNRF now has the technical 
and managerial capability to not only maintain this database, 
but also the ability to interface directly with other external 
systems such as NFC's PAYPERS and OPNAV's NMDAS. By removing 
this responsibility for SELRES data maintenance from NRPC, 
thousands of hand inputs per month could be eliminated. The 
resources of NRPC, being relieved of the tremendous 
responsibilities of maintaining the SELRES database could then 
be diverted to other crucial problems involving the remaining 
Naval Reserve database. 
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III. ISSUES CONCERNING FUTURE IMPROVEMENTS TO IMAFMIS 

In this chapter, management-related issues concerning 
information systems and how they relate to the problems and 
shortcomings of IMAPMIS will be addressed. Organizational 
issues, centralization/decentralization concerns, disputes 
over data ownership, problems of data quality and control and 
finally system Interface concerns will be discussed. These 
issues, each bearing significantly on the success of both 
NRPC and CNRF as organizations, exert a direct influence on 
the future of IMAPMIS and where SELRES database 
responsibilities belong. 

A. ORGANIZATIONAL CONCERNS 

The Installation of the first commercial computer in 1952, 
became the beginning of a new age of information technology 
(IT). Since that time, IT has evolved rapidly, with computer 
hardware technology and processing capability improving at the 
rate of 30 to 40 percent each year. Microcomputers of the 
late 1980s surpass the processing capabilities of the IBM 370 
mainfreune series of the early 1970s. 

Today, with the availability of vast amounts of data and 
relatively low cost equipment. Information is becoming 
increasingly important to the success of organizations. Due 
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to its expanded significance, information is widely being 
considered a valuable strategic resource. Its importance in 
achieving organizational objectives is regarded equally with 
personnel emd financial assets. 

The goal of organizations today, and the Navy is no 
exception, is to use information and information resources to 
achieve the greatest possible gain in mission effectiveness. 
However, in order to achieve this goal, plans for information 
systems development and usage must be aligned with strategic 
command objectives. Use of systems that do not support these 
goals will, in all likelihood, prove counterproductive to the 
command. Implementation of new technologies will provide 
better methods of accomplishing mission needs only if the long 
range information and data needs of the command are understood 
and systems are developed accordingly. The alternative 
courses of action that result from these plans may lead to 
changes in organizational structures and relationships in 
order to better realize advantages of new information 
opportunities (DOD (MPT),June 1987,p.5). Restated, 
orgemizations should: 

...base decisions regarding the need for new or improved 
automated information systems on a careful analysis of the 
current organizational functions and the ways that 
information systems are currently supporting them, and 
what is needed to meJce the organization (as a whole) more 
effective in accomplishing its goals. (DCNO (MPT),July 
1987,p.iii) 
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Designed to automate clerical functions and collect data, 
IMAPMIS was developed in support of NRPC's predominantly 
administrative organizational mission. Its primary function 
was, and is today, to support an efficient, effective 
mobilization of reserve assets by maintaining an accurate, 
comprehensive collection of information about members of the 
Inactive Naval Reserve. 

However, many of these reservists, the SELRES fall under 
the direct operational control of CNRF. The CNRF mission is 
to structure mobilization billets into effective and efficient 
\inlts and subsequently train and administer SELRES that will 
fill those billets. Dependent on IMAPMIS as his source 
system, CNRF is vitally interested in the way that IMAPMIS is 
managed, its responsiveness to his mission, and how future 
application development decisions are made. Information is 
of strategic importance and essential for CNRF's future 
success in a climate of shrinking budgets and increasing 
pressures for improved performance. Yet, IMAPMIS is 
administered and controlled by an organization that is not 
only external to CNRF, but is not even within the chain of 
command. CNRF is not receiving adequate support from IMAPMIS 
emd further, has absolutely no control over decisions 
regarding the future of IMAPMIS and data critical to mission 
accomplishment. 


61 






Thus, two highly disparate organizations with entirely 
different goals, must rely on a common database and processing 
system for support. At some point in the near future, it must 
be recognized that IMAPMIS cannot effectively support both of 
these incongruous missions simultaneously. Therefore, each 
command should closely exeunine and redefine its own internal 
information requirements and proceed with appropriate actions 
to accomplish them. 

This reexamination of the future of IMAPMIS and its 
ability to support both NRPC and CNRF missions involves a 
highly political issue of control. To be truly effective, the 
database and associated applications should more accurately 
reflect the attitudes, policies and goals that influence all 
aspects of CNRF. Without CNRF being able to exert any 
influence over these issues, IMAPMIS will continue to operate 
independently of this primary user. A recent study to combine 
the AOP application developments of both CNRF and NRPC into 
a single echelon three command that would act as a centralized 
design agency would finally allow input from the CNRF 
perspective and should be adopted. 

B. CENTRALIZATION/DECENTRALIZATION ISSUES 

Historically, management of information systems was 
centralized to enhance processing efficiency and enforce 
organizational policies. Applications were batch-oriented and 
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not easily distributed. With the rapid expansion of 
technology over the last decade, the demand for information 
increased. If users could not get responsive results from ADP 
departments, microcomputers were obtained for local use, 
circumventing centralized systems. This also created problems 
as control of data and policies was lost and islands of 
information developed. Data and applications proliferated, 
with little, if any, control or standardization. In the last 
few years, CNRF has experienced this dilemma of controlling 
end user computing and has now focused the use of 
microcomputers into building a distributed SELRES database 
that employs data structures and definitions established 
within the new IMAPMIS database. By incorporating information 
planning into the organization's long range goals, CNRF has 
directly confronted both organizational and 
centralization/decentralization issues. With foresight and 
resourcefulness, CNRF developed RTSS and RSTARS, a framework 
that provides CNRF with centralized strategic control of a 
large integrated information system and also offers geographic 
distribution of data entry and processing to operational 
levels (the NRAs). RTSS gives CNRF demonstrated capability 
to maintain a centralized master database. RSTARS affords 
commanding officers access to and the ability to update and 
manipulate critical SELRES and mobilization data on a daily 
basis using replicated partitions of the master database. 
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Although this approach may not be the most efficient method 
of data storage, it does successfully support the information 
needs of CNRF. Data is input at the NRAs on a daily basis and 
uploaded nightly to CNRF via modem. Once inputs are 
processed, the master database in New Orleans is the most 
current, most accurate database pertaining to SELRES eind 
mobilization billet structures. Additionally, this 
distribution solution affords a maximum level of backup 
capability in the event of a loss of the master database. 
Other factors, such as cost of communications and methods of 
update are the most efficient and effective possible given 
the equipment and budgets available. 

While the centralized management and control approach of 
IMAPMIS ideally supports the administrative, record-keeping 
mission of NRPC, it is unacceptable for the needs of CNRF. 
The decentralized, distributed structure of RTSS and RSTARS 
more adequately supports the operational requirements of CNRF. 

C. DATA Of9NERSHIP 

The central question still remains unanswered: who really 
owns the SELRES data? Is it NRPC, tasked with maintaining the 
records for all Inactive assets, or is it CNRF who actively 
uses and manipulates both personnel and mobilization billet 
data. 
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In the early days of computerized data processing, most 
systems were clerical In nature. Input, processing, output 
and storage functions were all the centralized responsibility 
of a single department. In this environment, the commonly 
accepted belief was that the data was "owned" by the 
application by which It was used. The department that 
developed these applications used them to justify budgets. 
Subsequently, since the ADP department paid for the system, 
they owned the data. 

However, with the Introduction of database systems, data 
Is now totally Independent of the applications. Data Is 
accessible by multiple systems and multiple users. Logically, 
In a database environment, ownership refers instead to the 
accountability of an individual for each data element. The 
task of assigning ownership of data within an organization Is 
normally coordinated by the database administrator among the 
various users. However, since IHAFMIS Is external to the true 
users of the data, there is little coordination between the 
users and NRPC. Therefore, there are no clearly defined 
responsibilities for data control exist. 

For example, CNRF is responsible to the Chief of Naval 
Operations for structuring mobilization billets and for 
training emd administering SELRES. To effectively accomplish 
these objectives, CNRF must have a reliable, accessible and 
responsive datedsase avalledale for dally transactions and use 
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in formulating management decisions. Alternatively, IMAPMIS 
merely reports information and processes updates submitted by 
CNRF. In many cases, data submissions by CNRF are not 
accurately updated within IMAPMIS (CNRF letter,? November 
1989). Does CNRF own the data or does NRPC? The answer 
depends entirely on who is asked. Surprisingly however, 
within the present IMAPMIS system architecture, CNRF has 
virtually no control of the data or data quality that directly 
affects the personnel resources he is responsible for 
training. 

D. DATA QUALITY 

Data quality can be viewed in many different perspectives. 
These encompass data integrity (or accuracy), completeness, 
timeliness and currency, and origin. Data integrity is 
perceived as a joint responsibility between the users, for 
actual contents and values, emd the database administrator, 
for logical data structures (Perry,1983,p.28). Control of 
lata integrity has historically been a constant source of 
irritation between CNRF and NRPC. For SELRES assigned to 
reserve units, quality data represents timely, accurate 
compensation for performed training. For CNRF it provides 
comprehensive, precise information about unit billet 
structures and the associated manning 2 md training levels of 
assigned personnel. These attributes are sorely lacking 
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within IMAPMIS, which seriously restricts the ability of CNRF 
to achieve assigned goals. 

One major difficulty in assessing accuracy of data within 
IMAPMIS is that it is not clear how all of the data is 
collected or input or which soiurce of data dominates others. 
With the numerous interorganizational Interfaces of IMAPMIS 
emd the volumes of input and output tapes used in processing, 
it is virtually impossible to determine which system overrides 
which and ultimately ascertain data origins. The data 
contained in the IMAPMIS database is full of errors and in 
many cases incomplete. 

A second problem, involves error detection. The lapse of 
time between data entry and error detection, has a direct the 
complexity of data correction. If errors are detected at the 
point of entry by built in edit checks and validation, then 
the probeibility of correction is very high. Conversely, if 
errors are not found for several weeks, minimal effort and 
time will be devoted to corrections (Davis and Olson,1985). 
Thus, the amount of time taken to identify errors seriously 
affects the data quality. In IMAPMIS, where errors may go 
undetected for weeks or even months, data quality problems 
abound emd will not, in all likelihood, improve. 

A third major problem in IMAPMIS is the result of a 
complete lack of enforceable stemdards of data quality for 
governmental information systems. Most directives and 
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instzxictions are vague and ambiguous (Laudon, January 1986). 
Without adequate guidelines for specifying data quality, that 
quality becomes difficult to define and even more difficult 
to enforce. Further, as long as IMAPMIS remains a large 
centralized database with multiple overlapping processes, 
control of data quality will continue to elude system managers 
no matter how good the data quality is at the point of entry. 

Most authorities on database quality agree that data 
should be captured and entered into any information system at 
its source . The question then becomes, what is the proper 
source of data. It is the contention of this thesis, that the 
best source of data for an Individual SELRES is the NRA where 
the member drills. Similarly, the authoritative origin of 
luiit stroictures should come from CNRF and not be overturned 
by IMAPMIS edits. Therefore, the data being input to IMAPMIS 
at the NRAs and through RTSS is in fact, the most recent, 
accurate data available. Further, this data, once validated 
by entry edit checks should be considered by all other systems 
as the data against which other data elements should be 
compared and updated. Presently, the system operates exactly 
the opposite with newly input data from the NRAs being 
compared to data already in the IMAPMIS database. 

The validation and edit checks completed at entry and at 
the CNRF level are sufficient to ensure that data is correctly 
updated. As the users "are made responsible for entering 
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their own data and for the accuracy of those data, the number 
of errors drops greatly..." (Martin,1981). Data entry, 
performed by local personnelmen or civilians who understemd 
what the data means, will also help ensure the completeness 
emd timeliness of the data emd subsequently improve the 
accuracy and quality of the master database. Although these 
fxinctions are being accomplished now at the NRAs, IMAPMIS 
interface edits that create high 'olumes of transaction 
rejections only serve to intensify the adversarial 
relationship between CNRF and NRPC. This is usually reflected 
in the attitude that "It's not my fault that things are 
screwed up: the computer did it". 

E. DATA AND SYSTEM INTERFACES/INTEROPEKABILITY CONCERNS 

Interoperability is the ability to share resources through 

plemned compatibility of technical resources; and further to 

use these capabilities to support functional requirements in 

the most effective emd cost efficient manner possible 

(OPNAVINST 5230.22,6 October 1986). 

It is extremely importemt that, in exchanges of automated 
data, the one receiving the data has the same 
Interpretation as the one sending it. This understanding 
is directly related to the definition of the data elements 
and the values of the data codes. (DOD 500.12-M,October 
1985,p.5) 

Due to original design of IMAPMIS and poor documentation, the 
numerous internal and external system interfaces are ill- 
defined. As previously discussed, in CNRF correspondence to 
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CMRF (CNRF letter,14 November 1989) the immediate need to 
correct these interface problems was fervently reiterated. 
SDP III also recognized the necessity for the upgrade of 
system emd process interfaces. Although major efforts have 
been dedicated within the Navy to develop standardized data 
definitions emd structures, those incorporated into the memy 
IMAPMIS subsystems have not yet been updated, and may or may 
not conform to these standards. 

With these problems in mind, it is easy to understand the 
antagonism between IMAPMIS program administrators and the data 
users. For the users, who are trying to maintain a quality 
dat 2 d}ase, it is frustrating to explain to a SELRES that he/she 
will not be paid for their previous drills because a hidden 
edit within IMAPMIS has rejected a valid transaction. No one 
seems to have a firm understanding of which system overrides 
another or who is ultimately responsible. 

F. LEGAL CONSIDERATIONS 

In addition to the operational issues addressed above, 

there are also legal ramifications to the present state of 

IMAPMIS. The Privacy Act of 1974 imposed a legal obligation 

that all computerized record systems must: 

...maintain all records which are used by the agency in 
making any determination about euny individual with such 
accuracy relevance, timeliness and completeness as is 
reasonably necessary to assure fairness to the individu¬ 
al... (P. L. 93-579: The Privacy Act of 1974) 
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Thus, information systems containing inaccurate, incomplete, 
eunbiguous information not only violate individual's rights, 
they are technically illegal. 

6. SUIQIARY 

The problem within IMAPMIS then becomes one of how to best 
resolve both management issues and the operational 
inadequacies. Constemt struggles at CNRF to control the data 
quality and ensure compliance with applicable statutes are met 
with resistance at NRPC. IMAPMIS developers, concentrating 
on administrative problems are occupied with an almost 
insurmountable challenge of transitioning IMAPMIS into a 
modem, responsive system. Under existing centralized 
m 2 magement control policies and focus on NRPC mission 
objectives, CNRF will not receive any relief in the 
foreseeable future. Alternatives must be examined that will 
support the future needs of both CNRF and NRPC. These needs 
should be pursued independently with NRPC continuing with 
IMAPMIS redesign emphasis on non-SELRES applications; and that 
CNRF forge on with expansion of RTSS and RSTARS, assuming 
management responsibility of the mobilization billet md 
SELRES datedaase. 

In the following chapter, a revised data flow architecture 
will be proposed that will provide a faster, more reliable 
alternative to awaiting future improvements to IMAPMIS. These 
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enhancements, that will surely be Insufficient for CNRF 
information needs are a classic case of too little, too late. 
The feasibility of establishing the SELRES database at CNRF 
and the emergent data flows it creates will be discussed. 
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IV. RECONMEMDEO DATAFLOW ARCHITECTURE 


It is common knowledge within the Naval Reserve Force that 
IMAPMIS is incapable of supporting the current information 
needs of CNRF. In fact, as far back as 1983 system planners 
wrote that: 

The redesign and rewrite of IMAPMIS is the most compelling 
need of all Inactive Requirements as the present system 
is the basic cause of numerous problems cited daily by 
users at all levels. (IMAPMIS SDP 1,1983) 

Since little has changed, it is now time to consider 

significant changes to the way SELRES data is controlled and 

processed. 

In regard to the inadequacies of IMAPMIS discussed in the 
previous chapters, it is strongly recommended that maintenance 
responsibility for the SELRES and Mobilization Billet database 
be removed from IMAPMIS/NRPC management and transferred to 
CNRF control. As has been previously mentioned, however, 
IMAPMIS is and will continue to be, under the auspices of 
NMPC, the official corporate repository for all Inactive 
Reserve data. Therefore, through the RTSS/IMAPMIS interface 
and PAYPERS processing, the CNRF database will continue to 
feed periodic data updates to IMAPMIS to satisfy currency and 
external reporting requirements. This approach will 
successfully support improved data quality for both CNRF and 


73 












IMAPMIS, minimize the need for changes in system interfaces, 
promote modular management information application 
development, and provide the information system structures 
that best suit both CNRF and NRPC. 

In this chapter, the actual changes in data flows that 
result from the new architecture as well as each of the 
improvements mentioned above will be discussed. 

A. CHANGES IN INFORMATION DATA FLOWS 

The information flows that existed in IMAPMIS prior to the 
introduction of RSTARS and the direct interface between NMDAS 
and RTSS are provided in Figure 5. Even with these 
improvements, many of the old data flows continued to exist 
as NRAs began using RSTARS and discontinued svibmission of 
diary entries directly to NRPC for input to IMAPMIS. 
Additionally, although RTSS is scheduled to receive billet 
data from OPNAV, CNRF must still svibmit hardcopy unit 
structures to NRPC for input to IMAPMIS for production of 
official unit manning and readiness reports. 

As can be noted from Figure 5, the number of organizations 
and internal and external systems that input data directly to 
NRPC imposed a tremendous burden on personnel and the system 
interfaces. With 419 NRAs submitting personnel and drill data 
on approximately 131,000 SELRES in addition to non-SELRES 
data requirements, both NRPC and IMAPMIS struggled to sustain 
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Figure 5. Existing SELRES Data Flow Architecture 
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existing levels of quality. Additionally, Figure 5 suggests 
the tremendous amount of data that was merely passed from one 
source to another with little processing. Specific examples 
include: 

1. The passage of unit structures from CNRF to NRPC for 
input into IMAPMIS. Once input, unit reports were 
generated and forwarded to the NRAs 

2. Personnel data, billet assignments, and drill 
participation data were submitted to NRPC. Drill 
chits and paper OCR documents were scanned to generate 
data tapes that were foirwarded for processing with 
IMAPMIS updates 

3. Unit authorizations from Director of Naval Reserve 
were sent to NRPC to either establish or discontinue 
reserve units. The information was input to IMAPMIS 
by NRPC personnel 

4. ACDUTRA completion data was also passed to NRPC from 
PSDs for input to IMAPMIS and eventual update of 
participation point credit 

These are only a few of the examples of data passing and the 
volume of transactions that were imposed on the NRPC staff. 

Figure 6 Illustrates a revised information flow 
architecture with full implementation of the NMDAS-RTSS 
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REVISED SELRES DATA FLOW ARCHITECTURE 



Figure 6. Revised SELRES Data Flow Architecture 
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interface and transfer of the SELRES/Hobilization database to 
CNRF responsibility. This simplified data flow will allow 
field activities to svibmit all personnel, billet assignments, 
drill participation and ACDUTRA data electronically to the 
central CNRF/RTSS database. Adequate validity and edit checks 
are incorporated at both the NRA and the CNRF level to ensure 
that data elements are correct and correspond to acceptable 
values and structures. Since data uploads and downloads are 
accomplished on a dally basis between each NRA and CNRF, the 
database is up-to-date and accurate within a 24-hour period. 
Data is no longer simply passed among commands awaiting entry 
or processing. 

B. CNRF MANAGEMENT CONCERNS 

The transition of a flat-file system to database 
technology is not merely a change in applications, it requires 
a change in management philosophy. CNRF has recognized the 
value of information as a strategic resource and has 
incorporated it into command long-term objectives. In recent 
years, with the development of RTSS and RSTARS, CNRF has 
established a distributed information system that supports 
commemding officers in the field with local SELRES and 
mobilization billet data as well as proving a centrally 
controlled dateUsase that is accessible and accurate. With 
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these resources totally under CNRF control, more effective 
and efficient decisions regarding mission accomplishment. 


C. APPLICATION DEVELOPMENT AND MANAGEMENT INFORMATION 
APPLICATIONS 

Some of the major objectives of using database technology 
are to speed up application development, generate better 
documentation, and reduce application maintenance costs. 
Applications for the RTSS/RSTARS systems are being developed 
in a modular approach and using higher level languages that 
simultaneously support navy directives and also significantly 
reduce development time and costs through the use of 
prototyping. 

Future applications will also include management support 
programs, to Include decision support systems (DSS), that will 
enhance the edaility of CNRF to more effectively and 
efficiently use limited resources to achieve major operational 
goals. 

D. SYSTEM INTERFACES 

The only interfaces that will change among the many 
organizations and systems with the revised information flow, 
will be the ested>lishment of a direct link capability between 
RTSS and PAYPERS. By initiating this interface, RTSS data 
cem be transmitted directly to PAYPERS for processing against 
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and with IMAPMIS tapes. This interface eliminates the need 
to hand-carry data tapes to NRPC who must then schedule the 
bulk data transfers using EPMAC facilities. 

With the already existent capability to download billet 
requirement data from NMDAS, no new interfaces need be 
established with OPNAV. This interface, which became 
effective in October 1989, has proven beneficial in both 
enhancing timeliness in receiving updated mobilization 
requirements and the ability of CNRF to more quickly structure 
reserve xinits. 

The interface between RTSS and IMAPMIS already exists and 
should not change other than to correct edit and validation 
problems that have already been identified. Even though the 
SELRES data may be controlled by CNRF, it is still vital that 
the data be transmitted to the NRPC data repository. 

In the future, it will no longer be necessary for NRPC 
to receive an enlisted or officer service record in house and 
a member record be established before the member can be 
affiliated in the Naval Reserve. New member information can 
be verified on the PAYPERS system during processing to ensure 
that the individual was a loss to active duty and to preclude 
allowing an individual to affiliate with more them one 
service. After this verification is complete, the member 
should be eligible for participation and pay. 
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B. BUNDLED TRANSACTIONS 


In regards to bundled transactions, RTSS development 
efforts should attempt to design an application modification 
that will accept a single entry, such as an advancement or 
unit transfer, and automatically generate the prerequisite 
entry for discharge or detachment from a previous unit. This 
will eliminate the need for dual entries to accomplish a 
single personnel change. If it is possible to tie the 
generated entry with the original entry, this may also 
alleviate the parallel processing problems encountered with 
the PAYPERS hardware suite. 

F. DATA OfiNERSHIP AND IMPROVED DATA QUALITY 

As discussed in chapter four, in order to enhance data 
quality, data should be entered at its source, and personnel 
who input the data should be held directly responsible for the 
quality. Today, the accuracy and quality of the CNRF database 
on SELRES is far superior to that of the database maintained 
by NRPC. Once the data flow architecture is revised, the data 
quality of IMAPMIS becomes the sole responsibility of CNRF. 
The data then should become the standard against which other 
data is compared and updated as necessary. No longer will the 
tail be wagging the dog, but the accurate SELRES data will 
update IMAPMIS. From the perspective of CNRF, there will be 
little change in business with the exception that, when a 
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correct and valid data entry is put into the database, there 
should be no external interface or processing requirement that 
will reject the transaction. Thus, in addition to betterment 
in CNRF performance and decision quality, there should be 
significant improvements in data reported to external sources. 
This will ultimately precipitate better policy and budget 
decisions in behalf of the Naval Reserve Force. 

G. SUMMARY 

In summary, by transferring the SELRES/Mobilization Billet 
database to CNRF control, many of the management issues 
previously addressed and the operational problems of IMAPMIS 
will be circumvented, NRPC program developers can then 
concentrate their future application efforts to those 
processes and interfaces that directly impact on the 
management of non-SELRES personnel. 

In chapter five, a brief summary of the inherent problems 
of IMAPMIS will be given, and followed by a synopsis of the 
effects that the revised information flow architecture will 
have on resolving these problems. 
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V. CONCUJSIONS 


Despite the fact that IMAPMIS is an antiquated system full 
of errors and unresponsive to either CNRF or NRPC information 
requirements, NRPC is still responsible for maintaining the 
Navy's corporate Inactive Naval Reserve datedsase. The 
original design and applications of IMAPMIS cannot be modified 
to efficiently support the new relational database. 
Therefore, all applications and interfaces must be carefully 
exeunined, evaluated and redesigned before any improvements 
will be noticeable. Further, the differences in 
organizational goals of NRPC and CNRF provide little common 
ground for future agreement on priorities for improvements or 
uses of IMAPMIS. 

To compensate for the poor support of IMAPMIS, and in an 
attempt to provide some internal command controls, CNRF 
developed his own database to more closely suit strategic and 
operational information requirements. Although this system 
(RTSS) is highly effective and used throughout the Naval 
Reserve Force, it still has not been permitted to solve any 
of the basic management and quality problems Inherent to 
IMAPMIS. RTSS emd RSTARS, the only data input sources for 
SELRES data were designed to control data redundancy, and 
ensure the timeliness and completeness of data. Even with 
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CNRF achievements in maintaining an accurate database, 
frequent IMAPMIS data overwrites and transaction rejections 
generated by antiquated edit and validity checks prove 
counterproductive. Sources of transaction rejections are 
virtually impossible to isolate and continue to hinder 
relationships between CNRF 2 uid NRPC. 

Without control of SELRES data, CNRF has failed to 
positively affect the quality of IMAPMIS. However, major 
innovative improvements have resulted from the development of 
RTSS and RSTARS. During the same time-frame as phase one of 
IMAPMIS, CNRF introduced microcomputers to NRAs and during the 
last year, has successfully transitioned from the archaic, 
time-consuming practice of updating SELRES data with OCR 
documents mailed to NRPC for scanning, to modern interactive 
data update and electronic data transfer capabilities. With 
the advantage of being able to design a new system rather than 
being constrained by trying to redesign an old system, CNRF 
was able to use a modern, modular development approach. The 
result is a highly successful, state of the art, distributed 
data system that is easy to use and update. The use of high 
level languages and Incorporation of microcomputers into the 
overall system architecture has earned widespread acceptance. 
Use of application generators for module development has 
enhanced documentation and ensured lower cost, more easily 
maintained applications. Additionally, RTSS and RSTARS lend 
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themselves to future management information applications 
including decision support systems (DSS) similar to that under 
development for mobilization billet structuring. 

This proposal, to extract the SELRES and mobilization 
billet database from NRPC responsibility, and to use the CNRF 
database to update NRPC records, is a preferred solution to 
memy IMAPMIS-related problems. Data quality will certainly 
improve and responsibilities and accountability are clearly 
defined. CNRF will be able to access accurate data for 
analysis and support of internal management decisions. And 
finally, data reported by IMAPMIS to external sources will 
more accurately reflect the true status of the Naval Reserve 
Force and will support improved policy and budget decisions 
in the future. 
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APPENDIX A 


GLOSSARY 


ACCPDS 

CDC 

DMDC 

EMF 

EPMAC 

FAD 

lEMF 

IFILMAN 

INAPMIS 

lOMF 

lOPAS 

IRIS 

MAD 

MANTIS 

MAPTIS 

NEOPS 

NES 

NMDAS 


Active Component Common Personnel Data System (DOp; 
Consolidated Data Center 
Defense Mempower Data Center 
Enlisted Master File (NMPC) 

Enlisted Personnel Manpower Center (NMPC) 

Foreign Address File (NRPC) 

Inactive Enlisted Master File (NRPC) 

Inactive File Maintenance (System) (NRPC) 

Inactive Manpower and Personnel Management Informa¬ 
tion System (NMPC/NRPC) 

Inactive Officer Master File (NRPC) 

Inactive Officer Promotion Administrative System 
(NMPC) 

Inactive Remote Inquiry System (NRPC) 

Master Address File (US Postal Service) 
ProgreuDming Language used with CINCOM's SUPRA 
M 2 mpower amd Personnel Training Information System 
Navy Enlisted/Officer Participation System (NRPC) 
Navy Enlisted System (NMPC) 

Navy Manpower Data Accounting System (OPNAV) 
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GLOSSARY (cont.) 


NRPDS 

NRURS 

OMF 

OPINS 

PERSPAY 

PH-PI 

PIMHS 

RCCPDS 

RESFIRST 

RESFMS 

RTSS 

RUAD 

RUMAS 

SOS 


Naval Reserve Drill Pay System (NRPC) 

Naval Reserve Unit Reporting System (NRPC) 

Officer Master File (OMF) 

Officer Personnel Information System (NMPC) 
Personnel and Payroll System 
Promotional History Transaction 

Pretrained Individual Manpower Management System 
(NRPC) 

Reserve Component Common Personnel Data System 
(DOD) 

Reserve Field Information Reporting System (NRPC) 
Reserve Financial Management System (NRPC) 

Reserve Training Support System (CNRF) 

Reserve Unit Assigned Document 

Reserve Unit Manpower Authorization System (NRPC) 
Source Data System (NMPC) 
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